AFRL-IF -RS-TR-2005-1 1 
Final  Technical  Report 
January  2005 


DISTRIBUTED  TRAINING  NETWORK  GUARD 
(DTNG) 


Trusted  Computer  Solutions 


APPROVED  FOR  PUBLIC  RELEASE;  DISTRIBUTION  UNLIMITED. 


AIR  FORCE  RESEARCH  LABORATORY 
INFORMATION  DIRECTORATE 
ROME  RESEARCH  SITE 
ROME,  NEW  YORK 


STINFO  FINAL  REPORT 


This  report  has  been  reviewed  by  the  Air  Force  Research  Laboratory,  Information 
Directorate,  Public  Affairs  Office  (IFOIPA)  and  is  releasable  to  the  National  Technical 
Information  Service  (NTIS).  At  NTIS  it  will  be  releasable  to  the  general  public, 
including  foreign  nations. 


AFRL-IF-RS-TR-2005-1 1  has  been  reviewed  and  is  approved  for  publication 


APPROVED:  /s/ 

ROBERT  M.  FLO 
Project  Engineer 


FOR  THE  DIRECTOR:  /s/ 

JAMES  W.  CUSACK,  Chief 
Information  Systems  Division 
Information  Directorate 


REPORT  DOCUMENTATION  PAGE 


Form  Approved 
OMB  No.  074-0188 


Public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  this  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information,  including 
suggestions  for  reducing  this  burden  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington,  VA  22202-4302, 
and  to  the  Office  of  Management  and  Budget,  Paperwork  Reduction  Project  (0704-0188),  Washington,  DC  20503 _ 


1.  AGENCY  USE  ONLY  (Leave  blank)  2.  REPORT  DATE  3.  REPORT  TYPE  AND  DATES  COVERED 

January  2005  FINAL  Mar  00 -Oct  03 


4.  TITLE  AND  SUBTITLE  5.  FUNDING  NUMBERS 

C  -  F30602-00-C-0027 

DISTRIBUTED  TRAINING  NETWORK  GUARD  (DTNG)  PE  -  63789F 

PR  -2743 

_  TA  -  00 

6.  AUTHOR(S)  WU  -  PI 

Jonathan  Beskin 
Linda  Schippler 
Romil  Sharma 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Trusted  Computer  Solutions 
2350  Corporate  Park  Drive 
Suite  500 
Herndon  VA  20171 


8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 


9.  SPONSORING  /  MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

AFRL/IFSB 

525  Brooks  Road 

Rome  NY  13441-4505 


10.  SPONSORING  /  MONITORING 
AGENCY  REPORT  NUMBER 

AFRL-IF-RS-TR-2005-1 1 


11.  SUPPLEMENTARY  NOTES 


AFRL  Project  Engineer:  Robert  M.  Flo/IFSB/(315)  330-2334 


12a.  DISTRIBUTION  /  AVAILABILITY  STATEMENT 


Robert.Flo@rl.af.mil 


12b.  DISTRIBUTION  CODE 


APPROVED  FOR  PUBLIC  RELEASE;  DISTRIBUTION  UNLIMITED. 


13.  ABSTRACT  (Maximum  200  Words) 

The  purpose  of  this  project  was  to  develop  a  Distributed  Training  Network  Guard  (DTNG)  to  allow  simulation  systems 
operating  at  different  security  levels  to  interoperate  within  a  common,  synthetic  environment,  thereby  enhancing  the 
capability  to  support  full  mission  training  and  rehearsal.  More  specifically,  the  objective  was  to  develop  and 
demonstrate  a  multi-level  security  (MLS)  network  guard  that  supports  distributed  simulation  training  systems 
interoperating  at  different  security  levels  within  a  High  Level  Architecture  (HLA)  environment. 


14.  SUBJECT  TERMS 

simulation,  distributed  simulation,  multi-level  security,  MLS,  high  level  architecture,  HLA, 
mission  training,  mission  rehearsal 


15.  NUMBER  OF  PAGES 


16.  PRICE  CODE 


17.  SECURITY  CLASSIFICATION  18.  SECURITY  CLASSIFICATION  19.  SECURITY  CLASSIFICATION  20.  LIMITATION  OF  ABSTRACT 
OF  REPORT  OF  THIS  PAGE  OF  ABSTRACT 


UNCLASSIFIED 


NSN  7540-01-280-5500 


UNCLASSIFIED 


UNCLASSIFIED 


Standard  Form  298  (Rev.  2-89) 

Prescribed  by  ANSI  Std.  Z39-18 
298-102 


Table  of  Contents 


1.  INTRODUCTION . 1 

1 . 1  GOALS/OBJECTIVE . 1 

1.2  COMPONENTS . 1 

2.  ARCHITECTURE . 3 

3.  PROCESSES  FOLLOWED . 7 

4.  HLA  SUPPORT . 8 

5.  PHASES/MILESTONES . 10 

6.  BUGS/ENHANCEMENTS . 13 

6. 1  PERFORMANCE  ISSUE . 16 

6.2  TIME  MANAGEMENT  SUPPORT . 1 8 

6.3  OWNERSHIP  MANAGEMENT  SUPPORT . 20 

7.  TRANSITION/FUTURE  WORK . 22 

8.  SUMMARY . 23 


1.  INTRODUCTION 

1.1  GOALS/OBJECTIVE 

The  United  States  Air  Force  has  embarked  on  a  major  effort  to  provide  the  warfighter  with  a 
simulation  training  environment  called  Distributed  Mission  Training  (DMT).  The  DMT 
global  network  concept  calls  for  interfacing  geographically  separated  simulations  (live, 
virtual,  and/or  constructive)  into  a  realistic  synthetic  training  environment  to  enable 
warfighters  to  “train  the  way  they  fight!”  However,  today’s  distributed  simulation 
environments  can  only  operate  at  a  single  system  high  security  level  since  there  are  no 
security  mechanisms  to  address  the  transfer  of  data  between  simulations  executing  at 
different  security  levels. 

Trusted  Computer  Solutions  was  tasked  to  develop  a  Distributed  Training  Network  Guard 
(DTNG)  to  allow  simulation  systems  operating  at  different  security  levels  to  interoperate 
within  a  common  synthetic  environment  thereby  enhancing  the  capability  to  support  full 
mission  training  and  rehearsal.  More  specifically,  the  objective  was  to  develop  and 
demonstrate  a  multi-level  security  (MLS)  network  guard  that  supports  distributed  simulation 
training  systems  interoperating  at  different  security  levels  within  a  High  Level  Architecture 
(HLA)  environment. 

1.2  COMPONENTS 

The  Air  Force  Research  Laboratory,  Warfighter  Training  Research  Division  (AFRL/HEA) 
Mesa  AZ  and  the  Information  Systems  Division  (AFRL/IFS)  Rome  NY  in  conjunction  with 
Trusted  Computer  Solutions  (TCS)  Inc.  Herndon  VA,  the  primary  development  contractor, 
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and  L3  Communications  at  the  Mesa  Research  Site  (MRS)  embarked  on  a  multilevel  security 
program  known  as  the  DTNG.  The  DTNG  program  has  designed  and  developed  both  a 
Trusted  Bridge  Federate  (TBF)  and  a  companion  Security  Reclassification  Rule  Set 
Intelligent  Assistant  Tool  (SRRSIAT).  Collectively,  these  two  components  are  referred  to  as 
the  DTNG. 

The  TBF  is  the  physical  real-time  automated  network  guard  component  that  supports  two- 
way  data  transfer  between  simulation  federations  operating  at  different  security  levels.  The 
SRRSIAT  is  a  stand-alone  interactive  graphical  user  interface  (GUI)  application  that 
provides  the  federation  security  classification/domain  expert  the  capability  to  develop  and 
review  classification  rules  that  govern  the  transfer  of  objects,  attributes,  interactions, 
parameters,  and  the  execution  of  cross  security  level  Run-Time  Infrastructure  (RTI) 
operations  for  cross  federation  object  models  (FOMs).  The  TBF  is  designed  to  be  FOM- 
independent  and  operates  using  a  subset  of  the  confederation  of  FOMs  that  include  the 
objects  and  interactions  that  can  cross  security  levels.  The  FOM  associated  with  any  specific 
exercise  forms  the  basis  for  all  the  objects  and  operations  against  which  filtering  and  guising 
rules  are  applied.  These  rules  can  be  simple  “yes/no”  rules  or  more  sophisticated  rules.  For 
example,  filtering  rules  may  be  to  zero  out,  clear,  or  null  the  data  values  of  attributes,  sub¬ 
attributes,  parameters  and  sub-parameters.  Guising  or  sanitizing  rules  allow  for  changing 
attribute  or  parameter  values  within  the  constraints  of  the  data  type. 
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2.  ARCHITECTURE 

The  TBF  architecture  is  illustrated  in  Figure  1 .  This  architecture  diagram  is  simplified  to 
show  two  federations,  each  operating  at  a  different  security  label,  each  with  its  own  RtiExec 
and  FedExec  process.  The  RtiExec  process  sends  messages  out  to  the  Federation,  and  the 
FedExec  process  receives  messages  from  the  Federation.  Both  of  these  are  provided  as  part 
of  the  RTI  library  from  MaK  Technologies  or  other  RTI  vendors.  Communication  between 
the  federations  is  accomplished  through  a  bridge  federate,  where  a  bridge  federate  has  been 
defined  as  follows: 

A  bridge  federate  is  a  federate  that  participates  in  multiple  federations.  It  is 
comprised  of  several  internal  components:  one  surrogate  federates  for  each 
participating  federation,  a  transfer  manager,  and  a  FOM  mapping  specification. 


Trusted  Bridge  Federate 


Figure  1.  Trusted  Bridge  Federate  Architecture 
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The  TBF  includes  an  Untrusted  Surrogate  Federate  (USF)  for  each  federation  operating  at  a 
different  security  label  and  a  single  Trusted  Bridge  Process  (TBP).  The  USF  processes 
operate  as  federates  on  the  trusted  operating  system  component  to  handle  the  cross-federation 
operations  for  all  federates  on  the  system-high  networks.  For  the  example  of  object 
publication,  a  USF  will  appear  to  publish  all  objects  published  by  federates  on  all  other 
federations  other  than  the  federation  operating  at  its  security  label  and  will  forward  on  all 
objects  published  by  its  federation  (that  have  been  released  by  the  TBP). 

There  is  no  direct  communication  between  the  USF  processes  executing  at  different  security 
labels.  Communication  between  the  USFs  occurs  through  the  TBP.  The  TBP  is  responsible 
for  mapping  and  processing  data  from  one  federation  to  another  federation.  It  perfonns  any 
necessary  modifications  of  the  data  in  accordance  with  the  security  policy  and  guarantees  the 
integrity  of  the  data.  It  also  includes  all  the  processing  necessary  to  manage  asynchronous 
communication  between  the  USFs. 

In  the  TBF  architecture,  every  federate,  in  all  attached  federations  including  the  TBF  itself, 
uses  the  confederation  FOM.  The  TBP  security  filter  only  passes  data  between  the  USFs:  (1) 
if  there  is  a  security  policy  for  that  object  or  interaction;  and  (2)  if  the  data  meets  the  security 
policy  rules  for  that  object  or  interaction. 

This  architecture  represents  the  most  efficient  approach  to  implementing  the  TBF.  It  is  not 
dependent  on  availability  of  RTI  vendor  source  code  and  does  not  require  any  modification 
to  the  RTI  specification.  It  also  consolidates  and  protects  the  “trusted”  software  on  the  trusted 
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operating  system  component.  The  USF  encapsulates  all  the  HLA  functionality  required  to 
communicate  with  other  federations,  while  the  TBP  encapsulates  all  of  the  security-relevant 
functions  as  well  as  all  communication  with  the  USFs. 

The  TBP  controls  the  execution  and  communication  between  the  USFs.  There  will  be  two  or 
more  USFs  connected  to  a  single  TBP,  one  for  each  federation  connected  to  the  guard  device. 
However,  standard  security  approval  processes  do  not  typically  pennit  direct  or  indirect 
connection  between  Top  Secret  Sensitive  Compartmented  Information  (SCI)  and 
Unclassified  systems.  Therefore,  connection  of  multiple  single-level  federation  networks  will 
likely  be  limited  to  single-step  interconnections.  For  example,  accreditation  approval  can 
reasonably  be  expected  for  connections  between  Top  Secret-SCI  to  Secret-US  and  Secret- 
Releasable  Levels  or  between  Secret-US  and  Secret-Releasable  Levels  to  Unclassified. 

On  startup,  the  TBP  reads  a  configuration  file  to  detennine  at  which  security  label  each  USF 
should  be  created,  and  how  to  start  the  USFs.  The  USFs  will  then  perform  normal  startup 
activities  for  a  federate  and  will  initiate  communication  with  the  RTI  for  its  federation. 

The  TBF  uses  the  confederation  FOM  but  will  only  operate  on  objects,  attributes, 
interactions,  and  parameters  for  which  there  are  security-filter  rules. 

Since  the  uniqueness  of  HLA  handles  is  only  maintained  within  a  federation,  the  TBF  must 
maintain  unique  identifiers  across  all  USFs.  Therefore,  prior  to  processing  any 
communication  between  federations,  the  FOM  will  be  processed  to  provide  the  following 
information: 
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•  A  list  of  object  classes,  where  each  is  mapped  to  a  unique  identifier 

•  A  list  of  interaction  classes,  where  each  is  mapped  to  a  unique  identifier 

•  A  list  of  attributes,  where  each  is  mapped  to  a  unique.  These  attributes  would 
additionally  have  a  data  type  and  a  data  size  associated  with  them.  This 
information  is  obtained  from  the  Object  Model  Template  (OMT). 

•  A  list  of  parameters,  where  each  is  mapped  to  a  unique  identifier.  These 
parameters  will  additionally  have  a  data  type  and  a  data  size  associated  with  them. 
This  infonnation  is  obtained  from  the  OMT. 

•  At  the  heart  of  the  TBF  is  the  security  classification  filtering  process.  For  each 
source  security  label  to  each  target  security  label,  filtering  rules  are  defined  based 
on  the  rule  set  defined  using  the  SRRS1AT. 

The  state  cache  holds  both  state  information  and  the  current  value  of  all  received  entity 
attributes  for  all  entities.  Entity  information  includes  the  most  current  value  of  all  attributes 
that  have  been  received  for  all  entities. 

In  addition  to  the  original  design  documentation,  Unified  Modeling  Language  (UML)  models 
were  created  to  support  the  design  effort.  These  models  are  difficult  to  reproduce  on  paper, 
but  have  been  included  on  the  CD  for  review.  The  files  are  SRRSlAT.mdl  and  TBF.mdl  for 
the  different  respective  projects. 
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3.  Processes  Followed 

As  much  as  possible,  TCS  engineers  follow  standard  development,  configuration 
management,  coding  and  review  processes  for  all  TCS  products,  both  commercial  and 
custom,  such  as  the  Trusted  Bridge  Federate. 

TCS  used  its  standard  C++  and  Java  programming  methodologies  for  the  DTNG.  These 
standards  are  attached  to  this  document,  named,  the  Trusted  Computer  Solutions  Guide  to 
C++  Programming  Style  and  the  Java  Coding  Conventions.  In  addition  to  these  standards, 
TCS  also  used  Scott  Meyers’,  Effective  C++  and  More  Effective  C++,  as  strict  guidelines  for 
developing  fast,  efficient,  readable  code  that  is  of  the  highest  quality. 

TCS  also  used  on  the  Trusted  Bridge  Federate  project  the  standard  TCS  configuration 
management  practices,  as  documented  in  the  attached,  TCS  Configuration  Management  Plan. 

Finally,  TCS  employed  a  system  of  biweekly  peer  review  for  all  design  and  coding.  This  was 
a  semi-formal  system,  whereby  the  individual  engineers  would  meet  on  a  daily  basis  to 
discuss  the  existing  design  and  development  strategies.  As  classes  and  methods  were 
developed,  all  members  of  the  team  were  consulted  for  design  issues  before  implementation. 
Every  two  weeks,  the  engineers  on  the  project  would  review  each  other’s  code  to  gain  fuller 
understanding  of  the  project  and  to  ensure  that  no  errors  were  being  introduced. 
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4.  HLA  SUPPORT 

The  High-Level  Architecture  (HLA)  mandate  establishes  a  common  high-level  simulation 
architecture  to  facilitate  the  interoperability  of  all  types  of  models  and  simulations  among 
themselves  and  C41  systems.  The  HLA  is  designed  to  promote  standardization  in  the  M&S 
community  and  to  facilitate  the  reuse  of  M&S  components. 

The  HLA  is  defined  by  three  components:  federation  rules,  the  HLA  Interface  Specification, 
and  the  Object  Model  Template  (OMT).  The  Run-Time  Infrastructure  (RTI)  software 
implements  the  interface  specification  and  represents  one  of  the  most  tangible  products  of  the 
HLA.  It  provides  services  in  a  manner  that  is  comparable  to  the  way  a  distributed  operating 
system  provides  services  to  applications. 

The  DTNG  has  used  implementations  of  the  RTI  from  two  major  companies:  DMSO  and 
MaK  Technologies.  The  TBF  initially  used  the  DMSO  RTI  but  a  decision  was  made  by  the 
Air  Force  in  conjunction  with  TCS  that  it  was  not  optimal  for  real-time  applications. 
Currently  the  DTNG  uses  and  supports  the  MaK  RTI  up  to  version  1.3.6  and  can  also  support 
all  versions  of  the  DMSO  RTI  with  minor  modifications.  An  effort  to  move  to  MaK  RTI 
version  2.0  is  currently  in  progress. 

The  TBF  currently  supports  Federation  Management  (Create,  Join,  Resign,  Saves,  Restores, 
Synchronization),  Declaration  Management  (Publish,  Subscribe,  Unpublish,  Unsubscribe), 
and  Object  Management  (Register/Delete  Object  Instance,  Attribute  Update,  Attribute 
Update  Requests,  Send  Interactions).  Management  Object  Model  (MOM)  calls  are  not 
handled  because  they  are  a  security  risk  for  federations  and  the  data  is  not  passed  to  the  TBF 


(by  design  of  HLA).  Time  Management,  Object  Ownership,  and  Data  Distribution 
Management  are  not  currently  supported  by  the  TBF  but  are  possible  enhancements  provided 
proper  funding  and  demand. 
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5.  PHASES/MILESTONES 

The  DTNG  program  consists  of  two  phases.  Phase  1  consisted  of  a  36-month  contract, 
beginning  March  2000  with  TCS  During  this  phase,  the  DTNG  (TBF  and  SRRSIAT)  was 
developed  using  a  spiral  schema.  Infonnal  demonstrations,  formal  T&E,  user  documentation, 
initial  certification  and  accreditation  support,  and  transition  to  ASC/YW  were  all  completed. 

Phase  2  (FY03-04)  called  for  support  to  an  ACC  Operational  Customer.  TCS  was  tasked  to 
perform  operational  site-specific  integration,  initial  operational  rule  set  development,  C&A 
support  documentation  development,  and  technology  transfer,  which  are  all  currently 
underway.  The  Operational  Customer  has  been  determined  to  be  TACCSF  in  Albuquerque, 
NM. 

The  DTNG  program  was  designed  with  two  spiral  enhancement  cycles  to  provide  adequate 
time  to  implement  corrective  actions.  After  each  spiral  enhancement,  tests  were  performed  to 
test  specific  functions  and  key  performance  measures. 

The  DTNG  TBF  Initial  Capabilities  Demonstration  was  successfully  demonstrated  on  July 
25,  2002.  A  series  of  vignettes  were  demonstrated  to  a  broad  range  of  the  M&S  community. 
Through  the  series  of  five  demonstration  vignettes,  eight  of  the  nine  functional  areas  of  the 
TBF  were  successfully  demonstrated.  The  nine  functional  areas  are: 

1 .  Rules  Library 

2.  Filtering  and  Cache 

3.  Trusted  Guard  &  Control 

4.  Message  Passing  Interface 
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5.  Inbound  Message  Handler 

6.  Outbound  Message  Handler 

7.  Human  Computer  Interface 

8.  Configuration  Support 

9.  Auditing 

The  security  auditing  function  had  not  been  completed  in  time  for  the  demonstration.  This 
vital  security  function  is  necessary  for  certification  and  accreditation  of  the  system.  This 
functionality,  as  well  as  the  continued  development  of  the  SRRSIAT,  was  all  addressed 
during  the  Spiral  1  Enhancement  phase. 

The  DTNG  Spiral  1  Test  was  conducted  6-10  January  03  with  the  primary  objective  of  the 
test  being  the  perfonnance  measurements  of  the  TBF,  since  a  key  performance  parameter  of 
the  system  is  to  provide  a  near  real-time  throughput  of  12MS  -  16MS.  The  test  was 
successfully  conducted  in  that  valuable  performance  data  was  collected  while  testing  the 
system  under  different  load  levels  and  test  conditions.  In  addition,  system  integration  test, 
security  testing,  and  audit  feature  capabilities  were  evaluated.  Unfortunately,  the  allotted  time 
devoted  to  the  remaining  test  was  insufficient  due  to  the  effort  placed  in  conducting  a  sound 
performance  measurement  test.  The  SRRSIAT  initial  capabilities  were  also  demonstrated 
although  the  system  still  required  additional  development  and  testing.  The  main  issue 
resulting  from  the  Spiral  1  Test  was  the  TBF  spike  latency  measurements  discovered  during 
the  extensive  perfonnance  measurements  test.  Also,  security  test  were  not  sufficiently 
extensive  to  determine  whether  all  basic  security  aspect  were  being  executed  properly. 
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The  DTNG  Spiral  2  Test  &  Demonstration  was  conducted  February  10-21,  2003.  Spiral  2 
enhancements  were  based  on  ensuring  security  and  auditing  features  of  the  system  were 
properly  installed  and  configured,  completing  the  SRRSIAT  modules,  and  resolving 
issues/problems  detected  during  Spiral  1  Test.  Spiral  2  Test  focused  on  the  performance, 
security,  and  auditing  capabilities  of  the  TBF,  and  SRRSIAT  functionality  and  GUI 
evaluation,  as  well  as  a  major  systems  capability  demonstration  of  the  DTNG  to  DoD 
organizations  and  contractors. 

The  SRRSIAT  functional  capabilities  were  demonstrated  by  developing  the  security  rule  set 
for  Vignette  5.  Once  the  rule  set  was  developed,  it  was  compiled  and  imported  into  the  TBF 
and  tested.  This  specific  capability  was  part  of  the  overall  demonstration  that  was  presented 
to  DoD  organizations  and  contractors. 

Trusted  Computer  Solutions  has  wrapped  up  the  DTNG  version  0.9  Beta  to  be  delivered  to 
the  US  Air  Force  by  the  end  of  October  2003  and  has  already  begun  Phase  2  of  the  program. 
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6.  BUGS/ENHANCEMENTS 

The  current  bugs  and  requests  for  enhancements  for  the  TBF  all  fall  between  Priority  3  and 
Priority  5.  None  are  critical  to  the  functionality  of  the  TBF.  They  are  as  follows: 

1.  Priority  3  -  Compartmenting  Issue 

With  Trusted  Solaris,  a  high  side  service  that  binds  to  all  interfaces  will 
receive  low  side  data.  This  would  mean  that  the  high  side  USF  receives 
federation  traffic  intended  for  the  low  side  USF  if  they  both  use  the  same 
port  number.  The  high  side  USF  then  sends  this  data  through  the  TBF  to 
the  low  side,  which  causes  an  infinite  loop.  It  may  be  possible  to  create 
and  use  separate  compartments  to  prevent  this  problem.  It  may  also  be 
possible  to  use  the  TCSccurcxFilter  component  to  enforce  this  security. 
These  solutions  need  to  be  tested. 

2.  Priority  3  -  Performance  Issue  (see  Section  7.1.1) 

The  TBF  seems  to  have  a  "spiking"  problem  in  its  performance.  About 
95%  of  the  data  passes  well  under  the  target  range  of  12-16ms  but  5%  of 
the  data  spikes  as  high  as  100ms.  The  exact  cause  has  not  yet  been 
determined.  One  possible  fix  might  be  converting  all  the  Unix  queues  to 
customized  Shared  Memory  Segments.  This  solution  would  be  an 
enhancement  to  the  TBF. 
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3.  Priority  3  -  No  Rule  Support  Against  RTI  Operations 


TBF  needs  to  support  rule  specifications  against  RTI  operations.  For 
example,  the  Rule  Library  should  be  able  to  handle  a  rule  such  as  “do  not 
allow  any  discover  object  instances  to  go  across.” 

4.  Priority  4  -  Rule  Generator  Needs  To  Generate  attributes.txt  Configuration  File 

The  TBF  needs  an  "attributes.txt"  file,  which  is  currently  being  generated 
by  a  Perl  script.  The  SRRSIAT/Rule  Generator  needs  to  be  able  to 
generate  this  file  upon  creation  of  libraries.  This  file  is  used  by  the  TBF  to 
map  class  and  attribute  names  to  the  internal  numbers  used  by  the  TBF. 

5.  Priority  3  -  Level  Issue  (FIXED) 

Currently  in  the  configuration  file  of  the  TBF,  it  is  necessary  to  have  the 
lines  in  the  correct  order  otherwise  it  is  misleading  as  to  which  is  the  high 
side  and  which  is  the  low  side.  Someone  not  careful  or  not  knowing  about 
this  constraint  might  get  confused  with  how  the  TBF  seems  to  be 
"reversed".  This  needs  to  be  corrected  to  make  the  configuration  file  easier 
to  work  with. 

6.  Priority  4  -  Simplify  Installation  Process 

The  TBF/Srrsiat  needs  a  simplified  installation  process  so  that  a  network 
administrator  can  install  both  products  easily.  In  addition,  an  icon  is 
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necessary  to  allow  the  TBF  to  be  run  by  someone  other  than  the  root  role, 
which  is  currently  necessary  to  allow  TCSecure:eFilter  to  operate. 

7.  Priority  3  -  Variable  Length  Data 

A  more  permanent  way  needs  to  be  implemented  for  data  coming  in  of 
variable  length.  Currently  there  is  a  work-around  by  "estimating"  the  max 
size  of  the  data  and  just  storing  it  in  a  character  array  and  allocating 
enough  memory  for  that  character  array. 

8.  Priority  5  -  Hanging  Child  Processes 

If  for  some  reason  the  TBF  exits  abnormally,  the  USF  processes  will 
continue  to  run,  and  the  TCSecure:eFilter  will  not  close  the  necessary 
ports.  If  the  user  is  unaware  of  this,  the  TBF  will  print  out  several  error 
messages  when  it  is  next  run.  The  TBF  needs  to  check  for  the  presence  of 
the  USF  processes,  and  force  them  to  shut  down  before  the  TBF  starts  up. 

9.  Priority  5  -  Add  Time  Managemen  t  Support  (see  Section  7.1.2) 

Adding  HLA  Time  Management  Support  can  be  done  if  necessary. 
However,  this  will  require  significant  effort  and  design. 

10.  Priority  5  -  Transition  to  MAK  2.0 

This  is  currently  being  dealt  with. 

11.  Priority  5  -  Ownership  Management  Support  (see  Section  7.1.3) 
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Adding  HLA  Ownership  Management  support  to  the  TBF  can  be  done  if 
required  by  the  customer.  This  is  a  significant  effort  and  considered  an 
enhancement  to  the  TBF. 


6.1  PERFORMANCE  ISSUE 

Performance  testing  conducted  in  the  Air  Force  Research  Laboratory  in  Mesa,  Arizona 
during  January  of  2003  showed  that  the  TBF  (Trusted  Bridge  Federate)  has  a  performance 
‘spiking’  issue  that  needs  to  be  addressed. 

The  target  throughput  requirement  of  the  TBF  is  12- 16ms  per  message  average.  Several 
variations  of  tests  were  conducted  including: 

•  Testing  without  the  TBF  to  give  us  a  baseline  network  latency 

•  A  simple  rule  set  that  passes  all  the  data 

•  And  a  complicated  rule  set.  For  our  experiment  we  chose  Vignette  1A. 

Different  loads  were  also  tested  from  low  (2  Viper  simulators  and  no  other  entities)  in  a 
single  direction  to  high  (2  Viper  simulators  and  20  entities  with  20  second  updates)  in  both 
directions.  All  tests  yielded  similar  results.  The  average  throughput  was  considerably  faster 
than  expected  (average  3.9  ms),  but  5-6%  of  the  data  peaked,  sometimes  as  much  as  100ms. 

It  was  theorized  that  this  might  be  due  to  a  lack  of  processors  on  the  system.  The  TBF  was 
tested  on  a  2  processor  SunFire  880  when  there  were  in  fact  4  main  processes  running 
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simultaneously  (TBF,  Low-Side  USF,  Fligh-Side  USF,  and  the  Trusted  Solaris  8  Operating 
System).  Upon  further  testing  with  a  4  processor  machine  at  Trusted  Computer  Solutions 
main  headquarters  in  Herndon,  VA,  it  was  determined  that  increasing  the  number  of 
processors  reduced  the  number  of  spikes  to  nearly  a  third.  Though  it  is  impractical  to 
guarantee  a  hundred  percent  of  the  data  to  pass  within  the  12- 16ms  threshold,  further 
investigation  may  help  in  reducing  the  percentage  of  spikes  significantly. 

One  possible  issue  may  lie  within  the  Unix  system  queues  that  are  being  used  by  the  TBF. 
These  queues  seem  to  be  slow  in  regards  to  real-time  applications.  This  may  be  because  the 
queues  are  filling  to  maximum  capacity  and  blocking,  and  thereby  causing  the  system  to 
spike.  A  quick  fix  to  this  problem  may  be  adjusting  the  maximum  size  of  the  system  queues 
enough  so  that  they  don’t  reach  a  maximum  capacity  in  a  realistic  training  exercise.  This 
may  temporarily  fix  the  problem  for  a  specific  training  exercise  but  it  surely  isn’t  a  cure-all 
for  the  perfonnance  problem.  A  level  of  effort  to  investigate  this  is  approximately  2  staff 
weeks. 

Another  area  worth  investigating  is  modifying  the  main  processes  to  be  “real-time”.  This 
might  minimize  the  number  of  blocks  and  interruptions  that  take  place  during  run-time  and 
might  minimize  performance  ‘peaks’.  Again,  this  may  temporarily  fix  the  problem  for  a 
specific  training  exercise  but  it  surely  isn’t  a  cure-all.  The  level  of  effort  to  investigate  this  is 
approximately  1  staff  month. 

Finally,  an  area  that  may  be  worth  a  few  months  effort  that  may  truly  minimize  the  spiking 
issue  (to  as  little  as  can  be  expected)  is  to  replace  the  system  queues  altogether  with  a 
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custom-written  shared  memory  management  interface.  This  will  possibly  rid  the  TBF  of  any 
delays  that  are  currently  being  caused  by  pushing  and  popping  messages  off  the  system 
queues.  Since  the  TBF  is  coded  entirely  in  C++,  only  modifications  in  implementation  will 
need  to  be  revisited  while  the  interface  can  remain  the  same.  This  is  the  advantage  of  having 
a  product  built  in  an  object-oriented  design  fashion.  Though  this  option  will  take  longer  than 
the  others  suggested,  it  is  very  possible  that  this  is  actually  what  needs  to  be  done  to 
minimize  the  performance  spikes  to  an  acceptable  percentage.  The  level  of  effort  to 
implement  shared  memory  is  approximately  3  staff  months. 

If  the  shared  memory  option  is  chosen  and  later  it  is  decided  to  increase  the  number  of 
processors  from  2  to  4,  no  additional  changes  to  the  system  will  need  to  be  made.  Since 
memory  is  separate  from  the  processors,  it  shouldn’t  have  any  effect  at  all.  Shared  memory 
will  not  cause  any  problems  with  Trusted  Solaris  or  any  of  its  security  features.  Shared 
memory  is  a  multilevel  resource,  exactly  like  the  Unix  queues  that  are  currently  used.  In  fact, 
the  queues  are  implemented  using  shared  memory  by  Trusted  Solaris.  So  there  should  be  no 
problem  with  security  or  accreditation  for  using  multilevel  shared  memory  structures. 


6.2  TIME  MANAGEMENT  SUPPORT 

Time  Management  in  HLA  is  a  set  of  services,  which  coordinate  the  advancement  of  logical 
time,  and  its  relationship  to  wall  clock  time  during  the  federation  execution.  A  main  goal  of 
time  management  is  to  support  interoperability  among  simulations  utilizing  different  internal 
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time  management  mechanisms  (message  ordering,  internal  time  flow,  transportation  services, 
etc). 

The  TBF  does  not  currently  support  Time  Management.  This  is  largely  due  to  the  fact  that 
the  TBF  was  designed  for  real-time  simulations.  The  TBF  can  be  redesigned  to  support  Time 
Management  but  the  implications  need  to  be  stated  and  understood. 

The  architecture  of  the  TBF  at  a  high  level  will  remain  basically  the  same  as  the  current 
design.  Significant  changes  will  need  to  be  made  to  the  message  passing  systems  between  the 
USFs  and  the  TBF.  This  will  add  a  level  of  synchronization  to  the  TBF.  Two  modes  of 
operation  (enable  Time  Management  and  disable  Time  Management)  will  have  to  be 
implemented  as  part  of  this  effort  to  support  customers  who  require  Real  Time  processing. 

Once  Time  Management  is  enabled,  performance  will  be  drastically  impacted  and  the  TBF 
will  not  run  at  real-time  speeds.  Time  Management  in  HLA  assumes  no  common,  global 
clock.  For  this  reason,  the  TBF  will  attempt  to  synchronize  time  between  federations.  This 
will  require  the  TBF  to  join  each  federation  as  being  time  constrained  and  time  regulating. 
The  TBF  will  need  to  be  the  last  federate  on  each  federation  to  advance  time  in  order  to 
maintain  synchronization.  This  will  cause  the  entire  simulation  to  slow  down  even  further. 
Only  after  knowing  the  details  of  how  Time  Management  is  handled  in  an  operational 
environment  can  it  be  concluded  whether  the  lag  time  will  be  acceptable  or  not. 

Adding  the  ability  to  support  Time  Management  does  not  severely  impact  security,  as  the 
TBF,  like  all  federates  that  are  time  constrained,  will  receive  messages  in  the  correct  time 
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order,  which  means  that  whatever  it  has  received  is  close  enough  to  “now”  that  it  makes  no 
difference  to  an  accreditor.  Some  filtering  would  have  to  be  done  on  the  time-related  data, 
but  not  a  significant  amount,  since  there  is  not  much  sensitive  data  there. 

The  level  of  effort  to  implement  Time  Management  is  approximately  8  staff  months. 
Considerable  modifications  need  to  be  made  to  the  TBF  and  the  SRRSIAT. 


6.3  OWNERSHIP  MANAGEMENT  SUPPORT 

The  TBF  does  not  currently  support  Ownership  Management  of  HLA  objects.  The  TBF  can 
be  redesigned  to  support  Ownership  Management  but  the  implications  need  to  be  stated  and 
understood. 

In  order  for  the  TBF  to  support  Ownership  Management,  it  would  have  to  use  the  GRIM 
RPR  2.0  FOM  or  some  variant  of  that  process.  There  are  two  ways  that  the  TBF  can  be 
modified  to  transfer  ownership  of  objects.  They  are  described  below. 

With  the  first  method,  TCS  will  only  modify  the  TBF  to  handle  Object  Ownership  HLA  calls 
and  not  worry  about  the  filtering  of  the  data  that  is  passed  during  the  ownership  transfer.  The 
GRIM  RPR  implementation  of  Ownership  Transfer  seems  to  require  a  DIS  method  for 
handling  this  data.  In  this  method,  TCS  will  not  implement  a  DIS  to  HLA  converter.  The 
customer  will  have  to  do  one  of  two  things  to  filter  the  data  properly  during  an  ownership 
transfer: 
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1 .  The  customer  can  implement  his  or  her  own  DIS  to  HLA  smart  filter.  It  should  be 
noted  that  this  would  be  a  significant  effort. 

2.  A  process  change  is  required.  Rather  than  data  being  sent  across  as  part  of  the 
ownership  transfer  interaction,  the  relinquishing  federate  would  publish  the 
necessary  data  via  the  nonnal  updateAttributeValues(  )  HLA  command.  The  TBF 
is  already  capable  of  handling  this  with  ease.  During  the  actual  transfer  of 
ownership,  the  “records”  portion  of  the  ownership  transfer  interaction  will  be 
dropped  and  the  data  will  not  be  passed.  This  means  that  all  federates  in  the 
exercise  will  have  to  implement  the  process  described  above  for  the  filtering  to 
work  properly. 

TCS  will  require  about  5  staff  months  to  implement  the  Ownership  Transfer  calls  for  either 
of  the  two  options  listed  above.  TCS  could  implement  a  DIS  to  HLA  converter  which  would 
ease  the  filtering  process  but  it  would  require  a  much  more  significant  effort  (about  24  staff 
months). 
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7.  TRANSITION/FUTURE  WORK 

The  DTNG  project  is  now  being  transitioned  to  an  operational  environment  at  TACCSF’s 
MLS  lab  in  Albuquerque,  NM.  Trusted  Computer  Solutions  will  release  DTNG  version  0.9 
beta  to  the  United  States  Air  Force  by  the  end  of  June  2003.  Trusted  Computer  Solutions  will 
then  make  an  effort  to  significantly  enhance/modify  the  TBF  by  implementing  and/or  fixing 
many  of  the  above-mentioned  bugs  and  enhancements.  Fixing  the  performance  issue  by 
implementing  shared  memory  segments  is  on  top  of  the  list  as  a  future  upgrade.  This  new 
version,  version  1.0,  will  then  be  part  of  Trusted  Computer  Solutions’  product  line  as  a 
COTS  product.  Version  1.0  will  be  the  first  version  to  completely  undergo  C&A. 
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8.  SUMMARY 

The  concept  of  Distributed  Mission  Training  (DMT)  calls  for  interfacing  geographically 
separated  simulations  into  a  realistic  synthetic  training  environment.  The  Network  Guard 
extends  this  concept  to  include  at  multiple  security  levels”. 

The  DTNG  Project  has  all  in  all  progressed  a  lot  further  than  initially  anticipated.  All  the 
major  milestones  have  been  met  and  transition  to  Phase  2  (real  operational  environment  and 
C&A)  is  currently  underway. 
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